1. Technical Field of the Invention
The present invention relates in general to the mobile communications field and, in particular, to a method for protecting cell and URA (Universal Mobile Telecommunications System Terrestrial Radio Access Network Registration Area) update message sequences.
2. Description of Related Art
The Universal Mobile Telecommunications System (UMTS) is the European version of the so-called third generation communication system, and is being developed under the auspices of the European Telecommunication Standards Institute (ETSI) The network component of the UMTS is referred to as the UMTS Terrestrial Radio Access Network (UTRAN). FIG. 1 is a block diagram of an architecture that has been developed for the UTRAN.
Referring to FIG. 1, the UTRAN architecture 10 shown includes a Core Network 12. A User Equipment (UE) 19, which is typically a mobile terminal, is used by a subscriber to access the services offered by an operator through the Core Network 12. The Core Network 12 is coupled to a Radio Network Controller (RNC) 16a, which controls radio resources and connectivity within a set of cells (e.g., cells 20a-e). Although only one RNC 16a is shown coupled via an interface to the Core Network 12, this arrangement is for illustrative purposes only. It should be understood that more than one RNC (e.g., 16a-c) can be coupled via an interface to the Core Network 12.
A cell (e.g., 20a) defines a geographical area where radio coverage is provided by radio transceiver equipment located at a radio base station site. Each such cell is identified with a unique identity, which is broadcast within that respective cell.
A URA (e.g., 18a) defines a geographical area composed of one or more cells (e.g., 20a and 20b). Each such URA is identified with a unique identity, which is broadcast within all cells belonging to that respective URA. As such, a URA can be composed of cells controlled by more than one RNC. A URA with cells controlled by more than one RNC can have an overlap between RNCs (i.e., an Overlapping URA).
A Signalling Network (e.g., Signalling System No. 7) 14 is coupled to the RNCs 16a-c. The Signalling Network 14 enables the RNCs to perform the requisite RNC-to-RNC signalling, in order to maintain established connections when a UE is moving between cells controlled by different RNCs in the Radio Access Network.
For each Core Network-UE connection, the role of an RNC can be two-fold. One role of such an RNC is that of a Serving RNC (SRNC). In this role, the RNC is in charge of the connection with the UE. In other words, this RNC has full control of this connection within the Radio Access Network. As such, this RNC is connected to the Core Network 12.
The second role of such an RNC is that of a Drift RNC (DRNC). In this role, the RNC supports the SRNC with radio resources for a connection with the UE, which needs radio resources in cells controlled by the DRNC.
Typically, the Radio Access Network 10 determines the role of an RNC (i.e., SRNC or DRNC) when the UE-Core Network connection is being established. Normally, the RNC that controls the cell where the connection to the UE is initially established, is assigned the SRNC role for this UE connection. As the UE moves, the connection is maintained by establishing radio communication branches via new cells, which can also involve cells controlled by other RNCs (e.g., DRNCs).
The above-described RNC roles are also relevant when a UE is using shared resources and experiencing at least some activity (i.e., some transfer of user data, or a CELL13 FACH state). Furthermore, these RNC roles are also relevant when a UE is using shared resources and operating in a low activity state (i.e., no transfer of user data, or a CELL13 PCH or URA13 PCH state). In the CELL13 FACH and CELL13 DCH states, the UE reports its location on a cell basis (Cell Update). In the URA13 PCH state, the UE only reports its location on a URA basis (URA Update). These RNC roles are relevant for all of the above-mentioned states, because control of the UEs in these states remains in the SRNC.
FIG. 2 is a diagram that illustrates state models for a UE. Referring to FIG. 2, a UE enters the Idle Mode 4 after power on. In this mode, the UE is not connected to the UTRAN. When a connection is established, the UE enters the Connected Mode 2. As such, there are four states in the Connected Mode. Each such state reflects a certain level of activity.
The CELL_DCH state 7 is characterized by a dedicated channel (DCH) assigned to the UE. Macro-diversity can be used between DCHs of several cells.
In the CELL_FACH state 8, no dedicated physical channel is assigned. However, the UE listens continuously to a common channel (the FACH) in the downlink belonging to the selected cell. In the uplink, the UE typically uses a random access channel (RACH). During each cell re-selection, the UE updates the network with the UE""s current cell location.
In the CELL_PCH state 6, the UE monitors a paging channel (PCH) of a selected cell. On the PCH, the UE uses discontinuous reception (DRX) to save power. The scheme about when the UE should listen is made in accordance with an agreement between the network and the UE, on a per UE basis. Also, at this point, the UE updates the network with the UE""s current cell location at cell re-selection.
The URA_PCH state 5 is similar to the CELL_PCH state 6. However, in the URA_PCH state 5, the UE only updates the network about the UE""s location after the UE has crossed a URA border. A URA is a group of cells. Consequently, in this state, the location of the UE is generally known only at the URA level.
FIG. 3 is a block diagram of the UTRAN architecture shown in FIG. 1, which further illustrates the RNCsxe2x80x2 roles. Referring to FIG. 3, RNC116a functions as an SRNC for the connections to UE119, UE227 and UE328. After successive Cell- or URA-Updates, the connection to UE227 is now routed via a cell 25 and URA 23a controlled by RNC216b, which functions as a DRNC for this connection. After successive Cell- or URA-Updates, the connection to UE328 is now routed via a cell 26 and URA 23a controlled by RNC316c, which functions as a DRNC for this connection.
FIG. 4 is a block diagram of the UTRAN architecture shown in FIG. 1, which illustrates how Cell-Update procedures are performed. As mentioned earlier, when a UE is in a CELL_PCH or CELL_FACH state, the UE reports a change in its location when it moves from one cell to another (Cell Update). Referring to FIG. 4, it can be seen that UE119 performs a Cell-Update when moving from cell 1:2 20b to cell 1:3 20c, UE227 performs a Cell-Update when moving from cell 2:5 25a to cell 3:1 25b, and UE328 performs a Cell-Update when moving from cell 3:3 26a to cell 3:4 26b. When UE328 performs a Cell-Update, the Cell-Update is conveyed to the SRNC for UE3 (i.e., RNC116a). The procedure used to convey the Cell Update to the SRNC is shown by the time-sequence diagram in FIG. 5.
FIG. 5 shows an RNC-to-RNC signalling procedure used to support a Cell-Update from an RNC (the DRNC) other than the RNC where the connection with the network was established (the SRNC). As shown by the procedure 30 in FIG. 5, the DRNC sends a Cell Update Request message 32 to the SRNC. In response, the SRNC sends a Cell Update Response message 34 to the DRNC. A corresponding procedure for use on the radio air interface, which is also referred to as a Cell-Update procedure, is described with respect to FIG. 6. As shown by the procedure 36 in FIG. 6, the UE sends a Cell Update Request message 37 to the RNC involved. In response, that RNC sends a Cell Update Response message 39 to that UE.
As mentioned above, when the UE involved is in a URA_PCH state (role), the UE only reports a change in its location when moving from one URA to another. This procedure is called a URA-Update. As such, the UE can remain in the URA_PCH state even after the URA-Update procedure has been completed (i.e., the next contact with the network is made when the UE passes a new URA border). Actually, even if the UE is typically in the URA_PCH state after the URA update procedure has been completed, there is a state transition during the URA update procedure. Since no uplink messages can be transmitted from the UE in the URA_PCH state, the UE moves from the URA_PCH state to the CELL_FACH state in order to perform the URA update procedure. In the URA_PCH state, the URA update request and response messages are exchanged. When the UE receives the URA update response message, the UE typically returns to the URA_PCH state.
FIG. 7 is a diagram of the Radio Access Network architecture of FIG. 1, which illustrates how URA-Update procedures are performed. Referring to FIG. 7, it can be seen that UE119 performs a URA-Update when moving from URA 118a to URA 218b. The UE227 does not perform a URA-Update despite having moved from a cell 25a controlled by RNC216b to a cell 25b controlled by RNC316c, with both of these cells within URA 518e. The UE328 performs a URA-Update when moving from URA 518e to URA 618f. 
Also as shown in FIG. 7, when the UE328 performs a URA-Update procedure, this information is conveyed to the SRNC for the UE3, or RNC116a. The procedure used to convey the URA-Update message to the SRNC is shown in FIG. 8. As such, the diagram in FIG. 8 shows the RNC-to-RNC signalling procedure used to support a URA-Update procedure from an RNC (the DRNC) other than the RNC where the connection with the network was established (the SRNC). The corresponding procedure performed on the radio air interface is also called a URA-Update. A diagram that illustrates the UE-to-RNC signalling procedure used to support a URA-Update from an involved UE is shown in FIG. 9. As such, referring to the procedure 46 shown in FIG. 9, the UE involved sends a URA-Update Request message 48 to the RNC involved. In response, the RNC sends a URA-Update Response message 49 to the UE.
The existing UMTS technical specifications include a function/procedure referred to as xe2x80x9cRelocationxe2x80x9d. The main purpose of this function/procedure is to transfer control of a particular UE from the SRNC to another node. The Relocation procedure covers both internal UMTS relocations and relocations to other systems (e.g., Global System for Mobile Communications or GSM). As such, the main purpose of a UMTS-to-UMTS relocation is to transfer the role of an SRNC from one RNC to another (e.g., if there is no support for RNC-to-RNC communication between the involved RNCs, or to optimize transmission).
Two types of Relocation functions/procedures have been defined. One type is Relocation with UE involvement. In this case, the role of the SRNC is transferred from one RNC to another at the same time the radio interface communication is handed over from one cell to another. The second type is Relocation without UE involvement. In this case, the role of the SRNC is transferred from one RNC to another without changing the cell being used for the radio interface communication. The Relocation function/procedure is carried out primarily via the Core Network-RNC interface.
Preferably, a Relocation is initiated by an SRNC. The Relocation can be triggered by a Cell Update or URA Update. However, a Relocation can also be triggered by other events. If a Relocation is triggered by a Cell Update or URA Update, then the response message to the UE is sent by the new SRNC.
Currently, the Cell-Update and URA-Update procedures in the UMTS do not account for the possibility that Cell Update Request messages or URA Update Request messages may be received by an SRNC xe2x80x9cout-of-sequencexe2x80x9d. In other words, although a certain Cell Update Request message (e.g., message A), can be sent by a UE prior to another Cell Update Request message (e.g., message B), the first (A) message can be received at the SRNC after the second (B) message is received. As such, there is no way to prevent problems from occurring during the operation of the cellular network due to the above-described phenomenon.
Currently, in the GSM, the Location Area Update message sent by a UE to the network (thereby reporting the location of the UE on a xe2x80x9cLocation Areaxe2x80x9d basis) includes information about the xe2x80x9coldxe2x80x9d Location Area. This information can be used by the network to avoid some of the errors resulting from those cases where the sequence of sent messages (also including signalling messages within the network) is not maintained.
A significant problem with the existing UMTS architecture is that if a UE is moving fast enough through the cellular network, the UE might initiate a Cell Update in one cell, and very soon after that, initiate a second Cell Update in another cell. If these two cells are connected to two different RNCs (e.g., cell A and cell B are controlled by different DRNCs, or cell A is controlled by the SRNC and cell B is controlled by a DRNC), the delay times that the two Cell Update messages are subjected to while being transported to the SRNC can be different. Consequently, the second Cell Update message can be received by the SRNC before the first Cell Update message. For similar reasons, the same problem can occur for two transported URA Update messages. In other words, if a UE is moving fast enough through the cellular network, the UE might initiate a URA Update in one cell, and very soon after that, change the URA (and cell) and initiate a second URA Update in another cell. If these two cells are connected to two different RNCs (e.g., cell A and cell B are controlled by different DRNCs, or cell A is controlled by the SRNC and cell B is controlled by a DRNC), the delay times that the two URA Update messages are subjected to while being transported to the SRNC can be different. Consequently, the second URA Update message can be received by the SRNC before the first URA Update message. As such, the existing UMTS specifications provide no way of ensuring that the sequences of Cell Update messages or URA Update messages are maintained from the UE to the SRNC.
Furthermore, the existing UMTS specifications include no methods for ensuring that the sequence of the Cell Updates or URA Updates, as perceived by the SRNC, is maintained the same as when the sequence is sent from the UE also after a Relocation of the SRNC""s role to a new RNC. Nevertheless, as described in detail below, the present invention successfully resolves the above-described problems and other related problems.
In accordance with a preferred embodiment of the present invention, a method for performing Cell- or URA-Updates in a mobile communication system is provided, whereby a UE sends a Cell-Update message or URA-Update message to an SRNC. The transported Cell-Update message or URA-Update message includes a sequence counter which is incremented each time the UE sends such a message to the SRNC. The SRNC stores the value of the sequence counter for each Cell-Update message or URA-Update message received and acknowledged. If the SRNC receives a Cell-Update message or URA-Update message with a corresponding sequence counter value that is lower than the sequence counter value stored for the previously received Cell-Update message or URA-Update message, then the SRNC ignores the received Cell-Update message or URA-Update message. Also, the SRNC does not store the sequence counter value for the ignored, received Cell-Update message or URA-Update message. Using this method, the SRNC can ensure that Cell-Update messages and URA-Update messages sent from a UE are handled in sequential order.
Furthermore, when a Relocation procedure is performed, the Cell Update sequence counter (Cell_Upd_Seq_No) and URA Update sequence counter (URA_Upd_Seq_No) is sent from the old SRNC to the new SRNC. If the Relocation procedure was triggered by a Cell Update, then the old SRNC sends the received sequence counter for Cell Updates, and the stored sequence counter for URA Updates. The new SRNC does not send the response to the Cell Update to the UE until the new SRNC has received the sequence counters (for both the Cell Updates and URA Updates) from the old SRNC. If the Relocation procedure was triggered by a URA Update, then the old SRNC sends the received sequence counter for URA Updates, and the stored sequence counter for Cell Updates. The new SRNC does not send the response to the URA Update to the UE until the new SRNC has received the sequence counters (for both the Cell Updates and URA Updates) from the old SRNC.
An important technical advantage of the present invention is that a method for performing Cell- or URA-Updates is provided, whereby an SRNC can ensure that only the last Cell-Update message or URA-Update message sent from a UE can be handled by the SRNC in those cases where the order in which the Cell-Update messages or URA-Update messages were sent by the UE is not maintained by the SRNC when received.
Another important technical advantage of the present invention is that a method for performing Cell- or URA-Updates is provided, whereby an SRNC can maintain accurate information about the location of a UE despite receiving out-of-sequence Cell-Update messages or URA-Updates messages from the UE.